Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-labarre-internetmib-iso-00.txt < prev next >

Wrap

Text File | 1993-03-03 | 137.6 KB | 3,099 lines

INTERNET DRAFT Expires April 23, 1993 ISO/CCITT and Internet Management Coexistence (IIMC): Translation of Internet MIBs to ISO/CCITT GDMO MIBs (IIMCIMIBTRANS) 9 October 1992 Lee LaBarre The MITRE Corporation Burlington Road Bedford, MA 01730 cel@mbunix.mitre.org Status of this Memo This memo provides information to the network and systems management community. This memo is intended as a contribution to ongoing work in the area of multi-protocol management coexistence and interworking. This memo is part of a package of ISO/CCITT and Internet Management Coexistence (IIMC) drafts; see also [IIMCOMIBTRANS] [IIMCMIB-II] [IIMCPARTY] [IIMCPROXY]. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, munnari.oz.au to learn the current status of any Internet Draft. Distribution of this memo is unlimited. Comments on this memo should be sent to iimc@thumper.bellcore.com by November 20, 1992. Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 Abstract This memo is intended to facilitate the multi-protocol management coexistance and interworking for networks that are managed using the OSI Common Management Information Protocol (CMIP) and networks that are managed using the Simple Network Management Protocol (SNMP). This RFC contains translation and registration procedures that are applicable to translation of Internet MIBs defined according to the Internet Structure of Management Information (SMI) into ISO/CCITT SMI defined MIBs. It also defines management information and SNMP trap to ISO/CCITT event mappings required for ISO/CCITT-Internet proxy. Table of Contents Status of this Memo ......................................i Abstract .................................................ii Table of Contents ........................................ii 1. Introduction ..........................................1 1.1 Background ...........................................1 1.2 Overview .............................................2 1.3 Scope ................................................4 1.4 Terms and Conventions ................................5 2. Registration and Naming Procedures ....................5 2.1 Registration Procedures ..............................5 2.1.1 Object Classes and Attributes Registration .........7 2.1.2 Notifications Registration .........................7 2.1.3 NAME BINDINGs Registration .........................8 2.2 Naming Procedures ....................................8 2.2.1 Naming Attribute ...................................8 2.2.2 ISO/CCITT-Internet Proxy Naming Tree ...............9 2.2.3 Distinguished Names ................................11 2.3 OID Translation ......................................12 2.3.1 OID/Name Translation: ISO/CCITT to Internet ........12 2.3.2 OID/Name Translation: Internet to ISO/CCITT ........13 2.4 Inheritance for Object Classes .......................14 2.5 Reference Labels for Derived Entities ................14 3. Internet to ISO/CCITT MIB Translation Procedures ......14 3.1 Pre-translation Procedures ...........................14 3.2 GDMO Translation Procedures ..........................16 3.2.1 Translation of Groups ..............................17 3.2.2 Translation of Table Objects .......................18 3.2.3 Translation of Table Entry Objects .................19 3.2.4 Translation of Other OBJECT-TYPES ..................20 3.2.5 Translation of Traps ...............................22 3.2.6 Translation of Internet Attribute Types ............24 3.3 Post-translation Procedures ..........................25 3.3.1 Post-translation of BEHAVIOUR Cause ................25 3.3.2 Post-translation of Notifications ..................26 3.3.3 Creation of NAME BINDING Templates .................27 LaBarre Page ii Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 4. ISO/CCITT-Internet Proxy MIB .........................28 4.1 Object and Attribute Definitions .....................28 4.2 Name Bindings ........................................34 4.3 Common SNMP Derived Attribute Types ..................35 4.4 Notifications for SNMP/SNMP-2 Traps ..................41 4.5 ASN.1 Definitions ....................................43 4.6 ISO/CCITT-Internet Proxy Communications ..............45 5. Acknowledgements ......................................45 References ...............................................46 LaBarre Page iii Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 1. Introduction The past decade has witnessed the development of enterprise wide networks composed of a multi-vendor environment containing heterogeneous protocol and hardware suites. Organizations have become increasingly dependent on these enterprise networks for their daily operations. This dependence has focussed attention on the need for operation, administration, maintenance, and provisioning (OAM&P) of the multi-vendor enterprise network on an end-to-end basis. 1.1 Background This memo is part of a package of ISO/CCITT and Internet Management Coexistence (IIMC) drafts. Other memos included in this package are: - Translation of ISO/CCITT GDMO MIBs to Internet MIBs (Newnan) [IIMCOMIBTRANS] - Translation of Internet MIB-II (RFC1213) to ISO/CCITT GDMO MIB (LaBarre) [IIMCMIB-II] - Translation of Internet Party MIB (RFC1353) to ISO/CCITT GDMO MIB (LaBarre) [IIMCPARTY] - ISO/CCITT to Internet Management Proxy (Chang) [IIMCPROXY] These memos together comprise a package aimed at integrating ISO/CCITT-based and Internet-based management systems. These memos are offered as input to coexistence and interworking efforts underway throughout the industry,including organizations such as: - IETF OSI Internet Management (OIM), - Network Management Forum Technology Convergence Team, - X/Open Systems Management (SysMan), - OIW Network Management Special Interest Group (NMSIG), and - OSF Management Special Interest Group (MANSIG). This work was initiated, in part, by NM Forum efforts to translate RFC 1214 for use with OMNIPoint 1 implementations. Through this effort, it became obvious that end-to-end management requires an integrated, unified view of the managed network, despite differences in management protocol and information structure. Integrated management can be facilitated by the development of "proxy" mechanisms which translate between functionally equivalent service, protocol, and SMI differences to create this unified view. MIB translation procedures can be used to support proxy management, as well as to take advantage of existing MIB definition and avoid duplication of effort. In this way, commercial investment in both ISO/CCITT and Internet-based LaBarre Page 1 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 management technologies can be preserved through deployment of common methods and tools which support integration. This overall strategy was outlined in a joint publication developed by the NM Forum and X/Open entitled "ISO/CCITT and Internet Management: Coexistence and Interworking Strategy" [NMFMC92]. The memos included in the IIMC package are intended as detailed specifications which implement several of the methodologies identified in this strategy. 1.2 Overview The response to the need for OAM&P of enterprise networks has been the development of network management standards within various networking communities - most notably the ISO/CCITT and Internet community. However, coordination of standards activities between these two communities has not occurred. As a result, although they share a nearly common management model, differences in their management protocols and structure of management Information (SMI) have developed due to differing management philosophies. The ISO/CCITT community has developed the Common Management Information Protocol (CMIP) [ISO9596], and related SMI documents [ISO10165-1,3,4]. The Internet community has developed the Simple Network Management Protocol (SNMP) [RFC1157], and is developing its successor, SNMP-2, based on [SMPPROT]. The Internet SMI is defined in [RFC1155] and [SMPSMI]. Although functionally similar, the Internet and ISO/CCITT protocols and SMIs differ in terms of their complexity and specific operations. The focus on the need for end-to-end enterprise management has indicated the need to integrate the management of components managed by ISO/CCITT management, Internet management and proprietary management mechanisms in a manner which presents a unified view of the network despite protocol and SMI differences. One way to integrate management is by the development of "proxy" mechanisms which translate between functionally equivalent services, protocol and SMI differences to create this unified view. A body of telecommunications and computer vendors, represented by organizations such as the Network Management Forum (NMF), and the U.S. government, as specified in the Government Network Management Profile (GNMP) have based their integrated management model on the ISO/CCITT management model using CMIP and the ISO/CCITT SMI. These organizations are particularly interested in the development of proxies for devices that use the Internet management protocols and SMI. Their interest is primarily due to the widespread commercial implementation and use of such devices within their enterprises, especially devices that use the Internet TCP/IP protocol suite. LaBarre Page 2 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 The basic model for ISO/CCITT-Internet proxy management is illustrated in the following diagram. Manager Proxy Agent +-----------------+ +----------------+ +-------------------+ |+---------------+| |+----++--------+| | +---------------+ | || Management || ||GDMO||Internet|| | | Managed | | || Applications || ||MIB || MIB || | | Resources | | |+---------------+| |+----++--------+| | +---------------+ | | | | |+--------------+| | | | | | | || Service || | | | | | | || Emulation || | | | | | | ||(scoping) || | | | | | | || (filtering) || | | | | | | || (operations)|| | | | |+---------+-----+| |+--------------+| |+--------+--------+| ||ISO/CCITT|GDMO || || Map Protocols | ||Internet|Internet|| || Manager |MIB || ||CMIS| |SNMP|| || Agent | MIB || |+---------+-----+| |+----+----+----+| |+--------+--------+| | | | | |CMIS | | | | | | |CMIS Services| | |Services | | | |SNMP "Services"| | | | | | | | | | | | | | | | SNMP| | | | | | | | | |"Services"| | | | | +-----------------+ +----------------+ +-------------------+ | CMIP | | CMIP | SNMP | | SNMP | +-----------------+ +----------------+ +-------------------+ ^ ^ ^ ^ | | | | +---------------+ +---------------+ CMIP Messages SNMP Messages The proxy architecture provides emulation of CMIS services by mapping to the corresponding SNMP message(s) necessary to carry out the service request. The service emulation allows management of Internet objects by an ISO/CCITT manager. The left hand side of the proxy behaves like an ISO/CCITT agent, communicating with the ISO/CCITT manager using CMIP protocols. The right hand side of the proxy behaves like an Internet manager, communicating with the Internet agent using SNMP protocols. The proxy relies on the existence of a pair of directly- related MIB definitions, where the Internet MIB has been translated into ISO/CCITT GDMO using the procedures specified in [IIMCMIBTRANS]. The proxy defined in [IIMCPROXY] uses these MIB definitions and rules to provide run-time translation of management information carried in service requests and responses. The proxy architecture is designed with a specified interface between the proxy and the underlying protocol LaBarre Page 3 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 stacks, and so deals primarily in terms of CMIS services and SNMP "services". The proxy emulates services such as CMIS scoping and filtering, processing of CMIS operations, and forwarding/logging of CMIS notifications by performing a mapping process which must be tailored for each protocol (for example, SNMP, Secure SNMP, and SNMP-2 are all variants of the same protocol mapping process). Finally, [IIMCOMIBTRANS] specifies translation procedures for converting ISO/CCITT GDMO MIBs into Internet MIBs. MIBs generated by this translation process cannot be utilized by the Proxy defined in [IIMCPROXY], although another kind of Proxy could be defined for this purpose in the future. 1.3 Scope A major reason for the rapid commercialization of devices manageable via the Internet management protocol is due to the speed with which the vendors in the Internet community have been able to develop MIBs based on the Internet SMI. To capitalize on this continuing Internet MIB development and their deployment in commercial devices, communities interested in integrated management via ISO/CCITT-Internet proxies require that procedures be defined for translation of Internet MIBs into ISO/CCITT GDMO MIBs, i.e., MIBs defined according to the ISO/CCITT SMI Guidelines for Definition of Managed Objects [ISO10165-4]. Such MIB translations may also minimize the independent development of ISO/CCITT GDMO MIBs for the same resources and thereby reduce the incompatibilities with the Internet MIBs. Of particular interest to the community interested in ISO/CCITT-Internet proxies, are translation procedures which may be automated to a high degree and include unambiguous automated registration procedures. This memo defines such procedures. This memo also defines the ISO/CCITT-Internet proxy management information and generic SNMP trap to CMIS notification mappings required for ISO/CCITT-Internet proxy managers, as well as common naming conventions and ASN.1 modules applicable to such proxies. This memo assumes that the reader is familiar with the ISO/CCITT SMI and Internet SMI, and the terminology of each. The term SNMP will be used throughout the memo to indicate either SNMP or SNMP-2, unless a distinction needs to be made. As of the publication date of this memo, the SNMP-2 SMI and protocol are evolving. It is expected that the [SMPPROT], [SMPSMI], [SMPMIB], [SMPTC] and related documents will be the basis of that evolution, and that changes will not LaBarre Page 4 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 significantly affect the registration, naming, and translation procedures described in this memo. Many, but not all, of the procedures defined in this memo are subject to automation. Comments are provided concerning possible aids to automation; however, it is not the intent of this memo to provide automated translation algorithms. 1.4 Terms and Conventions TBD 2. Registration and Naming Procedures Registration and naming procedures are crucial to the unique identification of management information. Registration assures the uniqueness of management information element types, while naming provides a way of distinguishing instances of a type and locating them within the MIB. 2.1 Registration Procedures Registration procedures specify that changes in the syntax or semantics of registered entities require them to be registered as new entities. The process of converting Internet MIBs into the ISO/CCITT GDMO MIBs inevitably introduces subtle semantic changes in how data can be operated on, and changes in the content of the MIB element. For example, ISO/CCITT attributes that are converted from Internet Object Types acquire matching rules for use in filtering operations. ISO/CCITT object classes that are created from Internet groups acquire semantics related to their inheritance of new attributes from the "top" managed object class. The end result is that all the new ISO/CCITT object classes, attributes, and notifications created during the translation process must be registered. In addition, name bindings for inserting object instances into the naming hierarchy must be registered. Registration procedures are critical to the goals of automating the translation of Internet MIBs to ISO/CCITT GDMO format, and the efficient implementation of ISO/CCITT- Internet proxies. Registration involves assignment of an ASN.1 Object Identifier (OID) to the entity. Management entities defined according to the principles of the Internet SMI may be registered under the IAB's "internet" arc, or registered under an arc in another organization's proprietary registration subtree. The effect of the registration procedure specified in this document is to graft the MIB elements defined as a subtree under the "internet", or proprietary, registration arc into another part of the registration tree without changing the subtree structure. LaBarre Page 5 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 For example, OIDs registered under the internet arc are of the form: OID = <internet> <internetEntityId> where <internet> is the full registration path to the "internet" arc; and <internetEntityId> is the portion of the OID that uniquely identifies entities under that arc, i.e., the remainder of the OID. OIDs registered under another organization's arc are of the form: OID = <organization> <internetEntityId> and <organization> = <org arc> <org internet part> where <org arc> is the arc assigned to the organization by ISO, CCITT, ANSI, or some other registration authority; <org internet part> is the path within the organization's subtree down to the subtree that identifies MIB entities defined according to the Internet SMI (an organization's internet subtree); and <internetEntityId> is that portion of the OID that uniquely identifies entities within the organization's internet subtree. Registration is accomplished by replacing the <internet> or <organization> portion of the OID with a new registration arc allocated for proxy registration such that the OID is of the form: OID = <cmipsnmpProxyXX> <internetEntityId> This procedure preserves the unique identification of the entities within the subtree, and since the new arc to which it is attached is unique, assures a unique OID. Also, since the original subtree information is present in the new OID, implementation of proxy translation of the corresponding management entities identified differently in the two SMIs is made easier. Internet defined groups and objects must be registered as ISO/CCITT object classes and attributes; Internet traps must be registered as ISO/CCITT notifications; and ISO/CCITT name bindings must be defined and registered. This memo assumes that an arc has been allocated in the registration hierarchy for use in ISO/CCITT-Internet proxy registration. The arc is named "cmipsnmpProxy". This memo assigns sub-arcs under "cmipsnmpProxy" as follows: cmipsnmpProxy OBJECT IDENTIFIER ::= {...} cmipsnmpProxyIMIB OBJECT IDENTIFIER ::= {cmipsnmpProxy 1} LaBarre Page 6 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 -- for ISO/CCITT derived object classes and attributes cmipsnmpProxyNB OBJECT IDENTIFIER ::= {cmipsnmpProxy 2} -- for ISO/CCITT derived NAME BINDINGS cmipsnmpProxyNOT OBJECT IDENTIFIER ::= {cmipsnmpProxy 3} -- for ISO/CCITT Notifications This memo assigns OIDs in 4.5 for registration of ISO/CCITT entities derived from internet entities registered under the "internet" arc, and for registration of entities defined in this memo. The following describes registration procedures to facilitate automated translation and assure uniqueness of registered ASN.1 object identifiers for ISO/CCITT object classes, attributes, and notifications derived from internet entities; and a registration procedure for their name bindings. 2.1.1 Object Classes and Attributes Registration Follow the procedure described in 2.1, using the internet assigned OID for the group, conceptual table, or conceptual table entry from which the object is derived, with {cmipsnmpProxyIMIB} substituted for {cmipsnmpProxyXX}. 2.1.2 Notifications Registration Notifications are registered using the OID corresponding to the value of the Internet smpTrapOID object defined in [SMPMIB]. For SNMP trap PDUs the smpTrapOID is derived as stated in the SNMP/SNMP-2 Coexistance memo [SMPCOEX] 4.1.2(2). That definition is repeated below: "... if the value of the generic-trap field is 'enterpriseSpecific' then the value used is the concatenation of the enterprise field from the trap PDU with additional sub-identifiers, '0', and the value of the specific-trap field." For traps defined according to the SNMP-2 SMI, the registered OID for the TRAP-DEFINITION macro is the value of the smpTrapOID. The registered OID for the ISO/CCITT derived notification is then translated from the value for smpTrapOID according to the procedures in 2.1 with {cmipsnmpProxyNOT} substituted for {cmipsnmpProxyXX}. 2.1.3 NAME BINDINGs Registration LaBarre Page 7 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 As described in 2.2.2 , the ISO/CCITT SMI requires that managed object instances be bound into a naming hierarchy, or tree, for purposes of naming. ISO/CCITT NAME BINDING templates are used to register the manner in which such instances may be bound. These name bindings must be registered. The Internet SMI does not include the concept of a naming tree and name binding. Thus, there exists no registered Internet entity from which an OID for the ISO/CCITT NAME BINDING template can be derived. One solution is to use the object class OID to register name bindings under an special registration arc {cmipsnmpProxyNB} which is different from the arc used to register notifications, object classes and attributes. The following procedure is recommended for registration of name bindings for an object class to be inserted into the naming hierarchy, i.e., the subordinate object class: o Replace the {cmipsnmpProxyIMIB} portion of the ISO/CCITT defined OID for the object class, derived using the procedures of 2.1.1, with {cmipsnmpProxyNB <sub-dentifier>}. The integer <sub-identifier> is used to distinguish possible multiple name bindings for the same object class. Sub-identifier values shall be greater than or equal to 1. 2.2 Naming Procedures ISO/CCITT object instances are identified by specifying read-only attributes within the object class as naming attributes. The naming attribute is used to form the relative distinguished name of the object instance. The sequence of relative distinguished names that trace the path in the naming hierarchy from the root to the object forms a distinguished name that uniquely identifies the object instance. 2.2.1 Naming Attribute The conversion of Internet MIBs into ISO/CCITT GDMO MIBs requires that naming attributes be defined and registered for each ISO/CCITT object class. This paper specifies a generic naming attribute, and the conventions for its value definition, to facilitate automated generation of naming attributes for object classes derived from Internet MIBs. This generic naming attribute is applicable to all ISO/CCITT object classes derived from Internet defined MIBs. The generic naming attribute, "internetClassId", is of ASN.1 type OBJECT IDENTIFIER with the following conventions for its value, as per the conventions in [RFC1212]: LaBarre Page 8 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 o For ISO/CCITT object classes that may have only a single instance per managed system, the value is the OID for the object class concatenated with a "0". Object classes derived from the Internet TCP, UDP, and IP groups are examples of such object classes. o For object classes that may have multiple instances per managed system, such as table entries, the value is the concatenation of the ISO/CCITT object class OID and the Internet object instance identification (an OID) of the form specified for the table entry instance identification in the original Internet MIB definition. The Internet object instance identification is the the concatenation of the values of the Internet OBJECT-TYPE(s) identified in the conceptual table entry OBJECT-TYPE INDEX clause. If an SNMP-2 AUGMENTS clause is present, the instance identification is the concatenation of the values of the OBJECT-TYPE(s) identifed in the INDEX clause of the table entry referenced in the value of the AUGMENTS clause. The formats for naming attributes of table entries are compatible with instance identification conventions used by the Internet, thereby facilitating the automated conversion of Internet MIBs into ISO/CCITT SMI format and the name mapping required for proxy management. 2.2.2 ISO/CCITT-Internet Proxy Naming Tree The ISO/CCITT SMI requires that managed object instances (conventionally just called managed objects) be bound into a naming hierarchy, or tree, for purposes of naming. This hierarchy is often called the containment hierarchy. The binding must specify for each managed object class: the object class which is superior to it in the containment hierarchy; and a naming attribute in the object class that is used to distinguish instances of the object class at a given level in the hierarchy. The name binding is specified after the object class has been defined. Multiple name bindings may be defined and registered that locate the object instances at different places in the naming hierarchy. This memo defines a subtree of the naming hierarchy for the ISO/CCITT-Internet Proxy MIB to be used in ISO/CCITT- Internet proxies. The subtree is rooted at the "cmipsnmpProxyTable" object defined in 4. Each entry in the table, called "cmipsnmpProxyAgent", corresponds to an SNMP agent in a managed system. MIB elements specific to each agent are subtrees of a "cmipsnmpProxyAgent" instance. LaBarre Page 9 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 One name binding for the "cmipsnmpProxyTable" object is specified which binds it to the ISO/CCITT "system" object class defined in [ISO10165-2]. Other name bindings may be specified. The ISO/CCITT-Internet Proxy MIB is organized using the conventions of tables and table entries to optimize the benefits of CMIS scoping. While this is not required by the ISO/CCITT SMI or CMIS, it minimizes the number of objects to which filtering must be applied, or the number of objects that are returned if filtering is not applied with scoping. A Naming Tree diagram for the ISO/CCITT-Internet Proxy MIB defined in this memo, the object classesdefined in the Party MIB [IIMCPARTY], and the MIB-II [IIMCMIB-II] is illustrated below. Although the ISO/CCITT "system" object class is shown to be the root of the tree, other object classes may be used. Object classes derived from groups in other Internet defined MIBs, that are specific to an SNMP agent, are bound to the "cmipsnmpProxyAgent" managed object, or to other objects within the cmipsnmpProxyAgent sub-tree as appropriate. "Rec. X.721 | ISO/IEC 10165-2 : 1992" : system | |-- cmipsnmpProxyTable | |-- partyTable --- partyEntry | |-- partySecretsTable --- partySecretsEntry | |-- aclTable --- aclEntry | |-- viewTable --- viewEntry | |--cmipsnmpProxyAgent | |-- partyTable --- partyEntry | |-- partySecretsTable --- partySecretsEntry | |-- aclTAble --- aclEntry | |-- viewTable --- viewEntry | |-- internetSystem | |-- at --- atTable --- atEntry | |-- egp --- egpNeighTable --- egpNeighEntry | |-- icmp | |-- interfaces --- ifTable --- ifEntry LaBarre Page 10 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 | |-- ip --- ipRoutingTable --- ipRouteEntry | | | |---- ipAddrTable --- ipAddrEntry | | | |-- ipNetToMediaTable --- ipNetToMediaEntry | | | |---- ipForwardTable --- ipForwardEntry | |-- snmp | |-- tcp --- tcpConnTable --- tcpConnEntry | |-- udp --- udpTable --- udpEntry 2.2.3 Distinguished Names The distinguished name (DN) of a managed object consists of a sequence of relative distinguished names (RDN), one for each managed object on the naming path from the root to the managed object. Each relative distinguished name contains exactly one attribute, the "naming" attribute for the corresponding class, as specified by a NAME BINDING template. This DN is used as the CMIP ManagedObjectInstance parameter for identifying managed objects. For example, a distinguished name designating a particular routing table entry (of class ipRouteEntry) might be { O O O -- higher level object RDNs {internetClassId = {cmipsnmpProxyPMIB 1 0}} -- cmipsnmpProxyTable {cmipsnmpProxyAgentId = "troi.mitre.org" } -- cmipsnmpProxyAgent {internetClassId = {cmipsnmpProxyIMIB 2 1 4 0}} -- ip {internetClassId = {cmipsnmpProxyIMIB 2 1 4 21 0}} -- ipRouteTable {internetClassId = {cmipsnmpProxyIMIB 2 1 4 21 129 83 2 17}} -- ipRouteEntry } The "internetClassId" naming attribute definition, to be used for object classes derived from the Internet MIBs, can be found in the ISO/CCITT-Internet Proxy MIB defined in 4 of this memo. 2.3 OID Translation The procedures required to translate between Internet registered OIDs and names, and ISO/CCITT registered attribute and class OIDs are described in this section. LaBarre Page 11 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 2.3.1 OID/Name Translation ISO/CCITT to Internet The general procedure for deriving ISO/CCITT registered OIDs from Internet OIDs was explained in 2.1, and the structure of the naming attribute value was explained in 2.2. This paragraph explains how the information used in an ISO/CCITT class OID, attribute OID, and the naming attribute value may be used to create the identifier for naming Internet objects. The following definitions apply: ((c) and (a) refer to class and attribute, respectively) From 2.1, {classOID} ::= {cmipsnmpProxyIMIB <internetEntityId>(c)} For example ipRouteTable ::= {cmipsnmpProxyIMIB 2 1 4 21 } where <internetEntityId>(c) ::= 2 1 4 21. {attributeOID} ::= {cmipsnmpProxyIMIB <internetEntityId>(a)} For example, ipRouteNextHop ::= {cmipsnmpProxyIMIB 2 1 4 21 1 7} where <internetEntityId>(a) ::= 2 1 4 21 1 7. From 2.2, the naming attribute value contains the OID formed as, (the "( )" indicates "contents of"): (naming attribute) ::= {cmipsnmpProxyIMIB <internetEntityId>(c) <internet instanceId>} where the <internet instanceId>, the OID created uniquely for each Internet object instance, is "0" for object classes that may only have a single instance. For example, the naming attribute value for the instance of ipRouteEntry specific to IP address 129 83 2 17 is {cmipsnmpProxyIMIB 2 1 4 21 1 129 83 2 17}, where <internetEntityId>(c) ::= 2 1 4 21 1, and <internet instanceId> ::= 129 83 2 17. The Internet uses the following convention to uniquely identify an Internet object instance: {internet object name}::= {<internet> or <organization> <internetEntityId>(a) LaBarre Page 12 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 <internet instanceId>} For example, the internet object name for ipRouteNextHop corresponding to IP address 129 83 2 17 is {internet 2 1 4 21 1 7 129 83 2 17}, where <internetEntityId>(a) ::= 2 1 4 21 1 7, <internet instanceId> ::=129 83 2 17. Therefore, given the contents of the naming attribute for the ISO/CCITT object instance being accessed the <internet InstanceId> and <internet> or <organization> are extracted. Given the attributeOID for the attribute being operated upon, the <internetEntityId>(a) is extracted. The {internet object name} is then formed from the results. For example, assume that a CMIS request is issued specifying a distinguished name for an ipRouteEntry managed object as illustrated in 2.2.3; and an attribute for ipRouteEntry, say ipRouteNextHop. The ipRouteNextHop attribute has been assigned the identifier {cmipsnmpProxyIMIB 2 1 4 21 1 7} in the MIB defined in [IIMCMIB-II]. Therefore, the ipRouteNextHop attribute identifier would first have to be translated into the corresponding Internet identifier {internet 2 1 4 21 1 7} by substituting "internet" for "cmipsnmpProxyIMIB". Then, from the RDN value for the ipRouteEntry extract the <internet instanceId> {129 83 2 17}. Finally the Internet identification for this piece of management information would be constructed according to RFC1213 as {ipRouteNextHop 129 83 2 17}, or equivalently, {internet 2 1 4 21 1 7 129 83 2 17}. The system in which this information resides is identified in the "cmipsnmpProxyAgent" RDN as "troi.mitre.org." 2.3.2 OID/Name Translation Internet to ISO/CCITT Given the definitions shown in 2.3.1, the ISO/CCITT {classOID}, {attributeOID}, and distinguished name can be derived from Internet OIDs and names. - The cmipsnmpProxyIMIB value is known. - The <internetEntityId>(a) value is extracted from the {internet object name}, and combined with the cmipsnmpProxyIMIB value to form the {attributeOID}. - The {classOID} can be determined by finding the ISO/CCITT object class to which the attribute identified as {cmipsnmpProxyIMIB <internetEntityId>(a) } belongs. NOTE: Avoid the temptation to derive the {classOID} from the {attributeOID} by assuming that the {attributeOID} ={classOID <integer>}. Sometimes post-processing procedures may combine attributes from multiple classes into a single class. See 3.3 for a discussion on this issue. LaBarre Page 13 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 2.4 Inheritance for Object Classes The "top" class defined by [ISO10165-2] is the ultimate superior in the ISO/CCITT inheritance hierarchy. The class "top" contains attributes which are inherited by all managed object classes that are defined using the ISO/CCITT SMI and GDMO templates. Not all attributes of "top" need to be instantianted in any single managed object. All objects should instantiate the mandatory "objectClass", and "nameBindings" attributes. If multiple packages may apply, an object should instantiate the "packages" attribute. 2.5 Reference Labels for Derived Entities The labels used to reference Internet entities (groups, objects, traps) should be used to reference the corresponding templates for the derived ISO/CCITT entity (object class, attribute, notification). 3. Internet to ISO/CCITT MIB Translation Procedures The procedures for translating Internet SMI MIBs into ISO/CCITT SMI MIBs consist of pre-translation procedures, GDMO template translation procedures, and post-translation procedures. Many of the procedures are subject to automation; some are not. Comments are provided concerning possible aids to automation; however, it is not the intent of this memo to provide automated translation algorithms. 3.1 Pre-translation Procedures Pre-translation procedures are outlined below. The rationale for steps (a) - (e) is that the ISO/CCITT object classes and associated attributes must be identified. The rationale for steps (f) - (g) is that all ASN.1 syntax references in templates must be an ASN.1 Externaltypereference or Externalvaluereference, i.e., must reference a label that appears on the left side of an ASN.1 construct within some ASN.1 module that appears in the document that defines the derived MIB. Internet MIBs often reference basic ASN.1 constructs, such as INTEGER and OCTET STRING, which must be converted into an Externaltypereference. Default values must reference an Externalvaluereference. (a) Identify Internet groups and OBJECT-TYPEs associated with each group. For SNMP-2 defined MIBs, the OBJECT-GROUP macro includes this information. For SNMP defined MIBs, the group may be identified manually and then the members of the group identified by the fact that their LaBarre Page 14 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 OIDs contain the group object identifier. For SNMP defined MIBs, procedure (c) must be followed. (b) Identify conceptual table OBJECT-TYPEs, conceptual table entry (row) OBJECT-TYPEs associated with each table, and columnar OBJECT-TYPEs associated with each conceptual table entry. Note: For SNMP-2 defined MIBs, the MAX-ACCESS clause of the OBJECT-TYPES macro will have a value of 'not-accessible' and the convention often used is to include the word "Table" or "Entry" in the macro label. Once a table has been identified the corresponding entry OBJECT-TYPE macro can be identified via its registered object identifier through the convention of appending a 1 to the table object identifier. SNMP defined MIBs are not so consistent in their use of "not-accessible"; however, the other conventions apply. Note: For SNMP-2 defined MIBs, tables may be defined with table entries that augment (SNMP-2 AUGMENT clause) entries for an existing table. The table object classes derived from such tables will be deleted from the ISO/CCITT MIB during post-translation (see 3.3.3). The table entry object class for the deleted table will be bound to the table entry object class that corresponds to the reference in the AUGMENTS clause. (c) For each group, the OBJECT-TYPEs not identified in procedure (b) and not having an ACCESS clause value of "not- accessible" are identified for translation into attributes of an ISO/CCITT object class. (d) For each conceptual table entry OBJECT-TYPE, the columnar OBJECT-TYPEs associated with the table entry and not having an ACCESS clause value of "not-accessible" are identified for translation into ISO/CCITT attributes of an ISO/CCITT object class. (e) For each conceptual table, an ISO/CCITT object class is created that contains the generic naming attribute "internetClassId". OBJECT-TYPES that are directly associated with the table become attributes of that table. (f) Create an ASN.1 module. For each OBJECT-TYPE that is to be translated into an ISO/CCITT attribute, check the value of the SYNTAX clause, and if it is not one of the Internet attribute types defined by the SNMP or SNMP-2 SMI (Counter, IpAddress, Gauge, TimeTicks, Opaque, Counter32, Gauge32, Counter64, NsapAddress), or defined using an SNMP-2 TEXTUAL-CONVENTION macro, then do one of the following: i) If the value is not an Externaltypereference: create an Externaltypereference for the value in LaBarre Page 15 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 the SYNTAX clause and put it into the ASN.1 module. ii) If the value is an Externaltypereference: put the Externaltypereference value into the ASN.1 module. The ASN.1 module is used for the GDMO template translations. g) Create an Externalvaluereference which has the type indicated by the OBJECT-TYPE SYNTAX clause and is assigned the value of the DEFVAL clause. For convenience, an ASN.1 module of common definitions for Externaltypereferences of the basic ASN.1 types included in the SNMP SMI and SNMP-2 SMI (e.g., INTEGER, OCTET STRING) is defined in 4.5. The Externaltypereferences in this module must either be imported into a local ASN.1 module within the document that defines the derived MIB, or appropriate equivalent references need to be declared within the local ASN.1 module. 3.2 GDMO Translation Procedures Readers of this memo are assumed to have familiarity with the GDMO templates and their format. The templates presented here should be considered exemplar, and not definitive. The GDMO templates in this paragraph contain elements indicated by "< x >", where "x" is to be interpreted and the result substituted into the template. The "||" symbol indicates concatenation of elements. Adjacent elements that are not concatenated should be separated by at least one space. The "[ ]" symbols surrounding a construct indicate that it may be present or absent in any particular instance of the template. The "[ ]*" symbols surrounding a construct indicate that it may be present or absent in any particular instance of the template an undefined number of times. An "|" symbol is used to indicate that a choice must be made between alternate constructs. The "!" symbol is used to delimit text strings in the templates. Other delimiters may be used, as specified by the GDMO. The delimiter may not be used in the text string unless it is "doubled", e.g., "!!". LaBarre Page 16 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 Elements that are defined in one template are not repeated for other templates unless changes are made to its interpretation. Note: other SNMP-2 SMI macro clauses contain textual or other information that may be inserted into the BEHAVIOUR clause of the an ISO/CCITT template, e.g., UNITS, REFERENCE. Provisions for including information in these macro clauses are not explicitly described in the translation procedures below, however the contents of these clauses should be included in the BEHAVIOUR clause. The Internet SNMP-2 SMI also includes macros for specifying compliance with the MIBs. These macros correspond to ISO/CCITT managed object conformance statements (MOCS), and are not addressed here. 3.2.1 Translation of Groups Internet groups may be translated to ISO/CCITT managed object classes by filling in the following GDMO template: <group label> MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top CHARACTERIZED BY <group label> || "Pkg" PACKAGE [BEHAVIOUR <group label> || "PkgBehaviour" BEHAVIOUR DEFINED AS !<optional textual definition>!;;] ATTRIBUTES internetClassId GET ["," <OBJECT-TYPE label n> <OBJECT-TYPE label n ACCESS clause translation> [DEFAULT VALUE <DEFVAL clause translation>]]*; [NOTIFICATIONS <notification label> ["," <notification label>]*;];; REGISTERED AS { {cmipsnmpProxyIMIB} <internetEntityId>(c) }; The following definitions apply: <group label> - The label associated with the Internet group. <optional textual definition> - Any textual description that is applicable to the resource modelled by this group, and the resource's management behaviour. Text in the SNMP-2 DESCRIPTION clause of the OBJECT-GROUP macro may be used. <OBJECT-TYPE label n> - The label of an Internet OBJECT-TYPE which is included in the group and does not represent a conceptual table, a conceptual table entry, LaBarre Page 17 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 or an OBJECT-TYPE included in a conceptual table entry. These become attributes of the object class. <OBJECT-TYPE label n ACCESS clause translation> - The mapping of the ACCESS (or SNMP-2 MAX-ACCESS) clause value as defined below (multi-valued attributes are not permitted in the Internet SMI): OBJECT-TYPE ACCESS Clause Value* ISO/CCITT read-only GET read-write GET-REPLACE write-only REPLACE read-create GET-REPLACE * OBJECT-TYPEs with an ACCESS clause value of 'not-accessible' will not become ISO/CCITT attributes. <DEFVAL clause translation> - The value of the DEFVAL clause in the form of an Externalvaluereference, i.e., <module-name>.<value-name>, where the module-name is the name of an ASN.1 module within the document in which this object class is defined, and the value-name is the label assigned to the ASN.1 value definition contained in the DEFVAL clause. Where it is necessary to refer to the label of a definition contained in another document, this may be achieved by means of a local ASN.1 module which makes use of the ASN.1 IMPORTS mechanism to import the appropriate value definition. 3.2.2 Translation of Table Objects Internet conceptual table objects may be translated to ISO/CCITT managed object classes by filling in the following GDMO template: <OBJECT-TYPE label> MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY <OBJECT-TYPE label> || "Pkg" PACKAGE [BEHAVIOUR <OBJECT-TYPE label> || "PkgBehaviour" BEHAVIOUR DEFINED AS !<OBJECT-TYPE DESCRIPTION clause text>!;;] ATTRIBUTES internetClassId GET ["," <OBJECT-TYPE label n> <OBJECT-TYPE label n ACCESS clause translation> [DEFAULT VALUE <DEFVAL clause translation>]]*; [NOTIFICATIONS <notification label> ["," <notification label>]*;];; LaBarre Page 18 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 REGISTERED AS { {cmipsnmpProxyIMIB} <internetEntityId>(c) }; The following definitions apply: <OBJECT-TYPE label> - The label associated with the OBJECT-TYPE macro. <OBJECT-TYPE DESCRIPTION clause text> - The text in the DESCRIPTION clause. 3.2.3 Translation of Table Entry Objects Internet conceptual table entry objects may be translated to ISO/CCITT managed object classes by filling in the following GDMO template: <OBJECT-TYPE label> MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY <OBJECT-TYPE label> || "Pkg" PACKAGE BEHAVIOUR <OBJECT-TYPE label> || "PkgBehaviour" BEHAVIOUR DEFINED AS !<OBJECT-TYPE DESCRIPTION/INDEX/STATUS clause text>!;; ATTRIBUTES internetClassId GET ["," <OBJECT-TYPE label n> <OBJECT-TYPE label n ACCESS clause translation> [DEFAULT VALUE <DEFVAL clause translation>]]*; [NOTIFICATIONS <notification label> ["," <notification label>]*;];; REGISTERED AS {{cmipsnmpProxyIMIB} <internetEntityId>(c) }; The following definitions apply: <OBJECT-TYPE label> - The label of an Internet OBJECT-TYPE which represents a conceptual table entry. <OBJECT-TYPE label n> - The label of an Internet OBJECT-TYPE which represents an OBJECT-TYPE included in a conceptual table entry. These become attributes of the table entry managed object. <OBJECT-TYPE DESCRIPTION/INDEX/STATUS clause text> - The text in the DESCRIPTION clause and the INDEX clause including the keyword INDEX. Note: in the post- translation phase, information about the status variable used for creation and deletion will be inserted. Note: Table object classes that contain table entry object classes which were derived from OBJECT-TYPES with an LaBarre Page 19 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 AUGMENTS clause will be deleted in the post-translation phase according to 3.3.3. 3.2.4 Translation of Other OBJECT-TYPES Other Internet OBJECT-TYPEs are translated into ISO/CCITT attributes by filling in the following GDMO template: <OBJECT-TYPE label> ATTRIBUTE [WITH ATTRIBUTE SYNTAX <module identification>|| "." || <SYNTAX clause translation 1> [MATCHES FOR <SYNTAX clause type matching rules>;] ] | [DERIVED FROM <SYNTAX clause translation 2>] [BEHAVIOUR <OBJECT-TYPE label> || "Behaviour" BEHAVIOUR DEFINED AS !<DESCRIPTION clause text>!;;] REGISTERED AS {{cmipsnmpProxyIMIB} <internetEntityId>(a)}; The following definitions apply: <module identification> - The label of the ASN.1 module that contains the ASN.1 syntax being referenced. The module must appear in the document that defines the translated MIB. ISO/CCITT have the concept of a generic "attribute type", which is a defined type that can be used in the definition of specific attributes. Attribute types have a defined syntax, generic semantics, and matching rules. For example, counter and gauge are attribute types. The SNMP-2 SMI has a similar concept embodied in the TEXTUAL-CONVENTIONS macro, which allows the definition of "Internet attribute types" with associated syntax and semantics. See 3.2.6 for translation procedures associated with the TEXTUAL CONVENTIONS macro. Attributes of the defined SNMP types (Counter, IpAddress, Gauge, TimeTicks, Opaque, Counter32, Gauge32, Counter64, NsapAddress) should inherit the semantics associated with the type - not just the syntax. As such, they could have been defined as Internet attribute types using a TEXTUAL CONVENTIONS macro. See 4.3 for the conversion of these types into ISO/CCITT attribute types. In addition, 4.3 contains ISO/CCITT attribute type definitions derived from [SMPTC]. Attribute templates derived from OBJECT-TYPE macros that specify these Internet attribute types in their SYNTAX clause should contain the DERIVED FROM clause. Attribute templates derived from other ASN.1 types should contain the WITH SYNTAX and MATCHING RULES clauses. LaBarre Page 20 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 <SYNTAX clause translation 1> - Translation of the SYNTAX clause into a valid type reference name using the ASN.1 Externaltypereference notation as GDMO requires. <SYNTAX clause type matching rules> - The matching rules for use in CMIS filtering operations. Note: This normally is a manual process; however matching rules that generally apply for some specific types are provided in the table below. These rules also to Externaltypereferences that reference the syntax type. These matching rules may be applied by automated mechanisms and then examined in the post- translation. Syntax Type Matching Rules INTEGER EQUALITY, ORDERING OCTET STRING EQUALITY, ORDERING, SUBSTRINGS BIT STRING EQUALITY OBJECT IDENTIFIER EQUALITY, ORDERING SEQUENCE EQUALITY Counter (x) EQUALITY, ORDERING * Gauge (x) EQUALITY, ORDERING * IpAddress EQUALITY, ORDERING SUBSTRINGS* NsapAddress EQUALITY, ORDERING SUBSTRINGS* TimeTicks EQUALITY, ORDERING SUBSTRINGS* Opaque EQUALITY, ORDERING* The * indicates the matching rules that are inherited from the ISO/CCITT attribute type as defined in 4.3. The (x) indicates counters and gauges of differing sizes. <SYNTAX clause translation 2> - Attributes of the defined SNMP/SNMP-2 types (Counter, IpAddress, Gauge, TimeTicks, Opaque, Counter32, Gauge32, Counter64, NsapAddress),and Internet attribute types defined using the SNMP-2 TEXTUAL CONVENTIONS macro, should be treated as ISO/CCITT attribute types. Specific attributes are derived from these types. The following table indicates the translations required for Internet attribute types as defined either in this memo or Internet documents. ISO/CCITT attribute types for Internet attribute types types are defined in 4.3. LaBarre Page 21 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 Syntax Type Substituted Value AutonomousType "IIMCMIBTRANS" :autonomousType Counter "IIMCMIBTRANS" :counter32 Counter32 "IIMCMIBTRANS" :counter32 Counter64 "IIMCMIBTRANS" :counter64 DisplayString "IIMCMIBTRANS" :displayString Gauge "IIMCMIBTRANS" :gauge32 Gauge32 "IIMCMIBTRANS" :gauge32 InstancePointer "IIMCMIBTRANS" :instancePointer IpAddress "IIMCMIBTRANS" :ipAddress MacAddress "IIMCMIBTRANS" :macAddress NsapAddress "IIMCMIBTRANS" :nsapAddress Opaque "IIMCMIBTRANS" :opaque PhysAddress "IIMCMIBTRANS" :physAddress RowStatus "IIMCMIBTRANS" :rowStatus TestAndIncrement "IIMCMIBTRANS" :testAndIncrement TimeInterval "IIMCMIBTRANS" :timeInterval TimeStamp "IIMCMIBTRANS" :timeStamp TimeTicks "IIMCMIBTRANS" :timeTicks TruthValue "IIMCMIBTRANS" :truthValue 3.2.5 Translation of Traps The Concise MIB Definitions [RFC1212] for SNMP does not contain a macro for representing traps since, in SNMP, traps were considered part of the protocol and not part of the MIB. A subsequent attempt was made to correct this problem in [RFC1215] by defining a TRAP-TYPE macro. The SNMP-2 SMI [SMPSMI] defines a TRAP-DEFINITION macro and its mapping onto an SNMP-2 PDU. The memo on SNMP/SNMP-2 Coexistance [SMPCOEX] defines a mapping between SNMP and SNMP-2 trap PDUs. Therefore, by inference, there exists a mapping of SNMP trap PDUs into an SNMP-2 TRAP-DEFINITION macro. This memo assumes that SNMP trap PDUs will be translated into SNMP-2 trap PDUs, and that by inference the mapping into a SNMP-2 TRAP-DEFINITION exists. The translation of Internet traps, as defined for SNMP Trap PDUs and the SNMP-2 TRAP-DEFINITION macro, may be translated to ISO/CCITT notifications by filling in the following GDMO template: <trap label> NOTIFICATION BEHAVIOUR "<trap label>" || "Behaviour" BEHAVIOUR DEFINED AS !<DESCRIPTION and OBJECTS/VARIABLES clause translation>!;; WITH INFORMATION SYNTAX <module identification>|| "." || "MonitoredAttributes"; -- MonitoredAttributes must be imported LaBarre Page 22 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 -- from Attribute-ASN1Module, defined in -- Rec. X.721 | ISO/IEC 10165-2 : 1992, -- into the ASN.1 module defined in the -- document that contains the MIB -- translation AND ATTRIBUTE IDS monitoredAttributes "Rec. X.721 | ISO/IEC 10165-2 : 1992" :monitoredAttributes; REGISTERED AS {<notificationOID>}; <trap label> - The label of the TRAP-DEFINITION (or TRAP-TYPE) macro, or one assigned by local means for SNMP enterprise specific traps. <DESCRIPTION and OBJECTS/VARIABLES clause translation>- The value of the TRAP-DEFINITION OBJECTS (or TRAP-TYPE VARIABLES) clause indicates the names of the attributes to be inserted into the monitoredAttributes field of the trap. A sentence indicating this fact should be inserted into the text of the DESCRIPTION clause and the result becomes the text for the template BEHAVIOUR clause. The text describing behaviour for SNMP traps and the attributes to be inserted into the monitoredAttributes field for traps not specified using a macro is not defined. The IpAddress of the SNMP agent in the SNMP Trap PDU is missing from the SNMP-2 TRAP-DEFINITION macro. The address may be inferred from the managed system's domain name in the "cmipsnmpProxyEntryId" RDN of the DN contained in the ManagedObjectInstance field of the CMIP event report that carries the notification. Similarly, the SNMP PDU "generic-trap", and "specific-trap" fields are missing from the SNMP-2 trap PDU and SNMP-2 TRAP- DEFINITION macro. The information contained in these fields are combined into the registered object identifier for the SNMP-2 TRAP-DEFINITION macro. This object identifier corresponds to the smpTrapOID object defined in [SMPMIB]. <notificationOID> - The OID for the notification as derived in 2.1.2. 3.2.6 Translation of Internet Attribute Types ISO/CCITT has the concept of a generic "attribute type", which is a defined type that can be used in the definition of specific attributes. Attribute types have a defined syntax, generic semantics, and matching rules. For example, counter and gauge are attribute types. The SNMP-2 SMI has a similar concept embodied in the TEXTUAL-CONVENTION macro, which allows the definition of LaBarre Page 23 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 "Internet attribute types" with associated syntax and semantics. Attributes of the defined SNMP types (Counter, IpAddress, Gauge, TimeTicks, Opaque, Counter32, Gauge32, Counter64, NsapAddress) should inherit the semantics associated with the type - not just the syntax. As such, they could have been defined as Internet attribute types using a TEXTUAL- CONVENTION macro. ISO/CCITT attribute types are defined using the ATTRIBUTE template, without the REGISTERED AS clause. <Internet attribute type label> ATTRIBUTE [WITH ATTRIBUTE SYNTAX <module identification>|| "." || <SYNTAX clause translation 1> [MATCHES FOR <SYNTAX clause type matching rules>;] ] | [DERIVED FROM <SYNTAX clause translation 2>] [BEHAVIOUR <Internet attribute type label> || "Behaviour" BEHAVIOUR DEFINED AS !<DESCRIPTION clause text>!;;] The following definitions apply: <Internet attribute type label> - The label associated with the TEXTUAL-CONVENTION macro, or with the generic type that could have been defined using that macro. Attribute templates derived from OBJECT-TYPE macros that specify Internet attribute types in their SYNTAX clause should specify the corresponding ISO/CCITT attribute types in their DERIVED FROM clause. 3.3 Post-translation Procedures Post-translation procedures generally includes manual checking of the BEHAVIOUR clause text for proper behaviour definitions, the addition of information concerning variables for creation and deletion, the assignment of notifications to an appropriate ISO/CCITT object class, and the creation of name bindings for placing the derived ISO/CCITT objects into the containment hierarchy. However, sometimes the procedures are not so straightforward. Post-translation procedures may result in deletion of some ISO/CCITT MIB elements derived from the procedures described in 2.2. For example, if the table object class contains entries that were derived from Internet OBJECT-TYPES that contained an AUGMENTS clause, then the table is deleted from the MIB. LaBarre Page 24 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 Post-translation procedures may also result in the combination multiple ISO/CCITT MIB object classes to form one class. The multiple object classes should perhaps belong to a single object class, but were created as separate object classes due to specific SNMP SMI requirements. The resulting multiple object classes may be constrained to synchronize their behaviour, e.g., to synchronize creation and deletion procedures. However, when viewed from an ISO/CCITT context, the rationale for using multiple objects may disappear, or ISO/CCITT SMI and protocol constraints may prohibit their use. See [IIMCPARTY] for an example of this situation. 3.3.1 Post-translation of BEHAVIOUR Cause The SNMP and SNMP-2 text descriptions often contain SNMP/SNMP-2 protocol, or SMI, relevant information that is inappropriate for an ISO/CCITT object class or attribute; such text should be removed or properly modified. A reference to the Internet MIB entity from which the ISO/CCITT entity was derived should be added. Descriptions of circumstances that cause the generation of specific notifications should be included. Information should be added that is relevant to attributes for instance identification and creation/deletion status. Such information should be added in a way that facilitates automated parsing of the BEHAVIOUR clause. The use of keywords is recommended. Multiple instance objects should be indicated by the keywordS "MULTIPLE INSTANCE" in the text. The text should include relevant information related to instance identification in the form of the full INDEX or AUGMENTS clause. The status variable, and its value for deletion, must be described for table entries that may be created and deleted by management action. The following format should be used: STATUSVAR ::= <label> STATUSDELETE ::= <value> where <label> is the label of the attribute used to indicate deletion of an entry, and <value> is the value which indicates deletion. The value specification should be consistent with the type of the status attribute. 3.3.2 Post-translation of Notifications LaBarre Page 25 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 The ISO/CCITT SMI models notifications as being emitted by specific managed objects. As a consequence, notifications must be assigned to appropriate object classes at the time the object class is defined. New notifications cannot be added to an object class without changing its registration. The fact that the ISO/CCITT SMI models notifications as being emitted by specific managed objects implies that notifications may only contain information known to the managed object. However, the Internet SMI has no explicit concept of traps being associated with an object. They may contain information related to multiple internet objects. Consequently, some notifications may be derived from SNMP traps that contain variables not affiliated with the same derived ISO/CCITT object class. This memo allows variables to be placed into a notification even if they are not attributes of the object class from which the notification is emitted. The following procedures should be applied: 1) identify the object class that corresponds to the resource to which the notification applies. 2) insert the notification into the NOTIFICATIONS clause of the object class. 3.3.3 Creation of NAME BINDING Templates The ISO/CCITT name bindings for object classes to be bound into the naming hierarchy described in 2.2.2 are created by filling in the GDMO template defined below. <object class label>-NB NAME BINDING SUBORDINATE OBJECT CLASS <object class label> AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS <superior object class label> AND SUBCLASSES; WITH ATTRIBUTE internetClassId; [CREATE [<create modifier>] ;] [DELETE [<delete-modifier>];] REGISTERED AS { <name binding OID>}; <object class label> - the reference label of the object class to which the name binding applies. <superior object class label> - the reference label of the superior object class in the naming hierarchy. Object classes derived from groups normally have the "cmipsnmpProxyAgent" object class as their superior. Table object classes, derived from conceptual tables, have the object class derived from the group in which LaBarre Page 26 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 they were defined as their superior. One way to determine the group is to use the structure of the OID for the table object, i.e., it contains the internet specific portion of the OID for the group. However, if the table object class contains entries that were derived from Internet OBJECT-TYPES that contained an AUGMENTS clause, then the table is deleted from the MIB. The reason for this is that the ISO/CCITT SMI prohibits adding attributes to an object class. The solution used in this memo is to make a table entry object class that augments another table entry the direct subordinate of the table entry object class being augmented. The table is no longer needed. Table entry object classes, derived from conceptual table entries, have the corresponding table object class as their superior. One way to determine the table is to use the structure of the OID for the table entry object class, i.e., it contains the internet specific portion of the OID for the table.However, table entry object classes derived from OBJECT-TYPES that contain an AUGMENTS clause have the table entry object class derived from the OBJECT-TYPE referenced in the AUGMENTS clause as their superior. The Internet SMI only allows the possibility of conceptual table entries being created and deleted. Many table entries are automatically created and deleted as a result of normal resource operation. For SNMP-2 defined MIBs, if the table entry contains an OBJECT-TYPE that has a SYNTAX clause value of "RowStatus" and a MAX-ACCESS clause value of "read-create", then the table entry may be created and deleted. For SNMP defined MIBs, the use of an OBJECT-TYPE within a table entry which indicates "RowStatus" is inconsistant. Usually, the text definition for the table entry may need to be consulted to determine if creation and deletion are allowed, and the columnar object and associated value which indicates deletion. <create modifier> - the "WITH-AUTOMATIC-INSTANCE- NAMING" modifier should be part of the CREATE clause if the object class is being used for proxy. This allows the proxy, which is closer to the resource than the manager, to assign instance names. The "WITH- REFERENCE-OBJECT" may also be be used. <delete-modifier> - The delete modifier for the DELETE clause should be "DELETES-CONTAINED-OBJECTS" if the table entry contains an object class added as a result of an SNMP-2 OBJECT-TYPE AUGMENTS clause. LaBarre Page 27 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 <name binding OID> - As defined in 2.1.3. 4. ISO/CCITT-Internet Proxy MIB The ISO/CCITT-Internet Proxy MIB defines a set of objects for specifying the information that is needed for both community-based and party-based SNMP management on a per SNMP agent basis. The ISO/CCITT-Internet Proxy MIB defines the "cmipsnmpProxyTable" object class which contains entry object classes named "cmipsnmpProxyAgent". The "cmipsnmpProxyAgent" has information to identify SNMP agents and how they may be reached. Its naming attribute, which contains the administratively assigned name of the managed device where the SNMP agent is located, is used in the naming hierarchy to identify the SNMP managed device. The definition of these two object classes and their attributes are defined in 4.1. 4.1 Object and Attribute Definitions ISO/CCITT-Internet proxy MIB object classes and attributes are assigned OIDs under the {cmipsnmpProxyPMIB} arc. The Internet convention of registering attributes under the object class to which they belong is followed in this memo. cmipsnmpProxyAgent MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY cmipsnmpProxyAgentPkg PACKAGE BEHAVIOUR cmipsnmpProxyAgentPkgBehaviour BEHAVIOUR DEFINED AS !This managed object class is used to represent an SNMP/SNMP-2 agent in the proxy MIB. Each agent that the proxy manages is represented by an instance of this object class. The cmipsnmpProxyAgentId attribute contains the administratively assigned name of the managed system that contains the SNMP/SNMP-2 agent. Usually this is an Internet Domain Name. The value is determined by the manager when the object is created. The proxyOID attribute contains the proxy arc used in the re-registration and derivation of OIDs. The following sub-arcs are assigned: {<proxyOID> 1} - object classes, attributes LaBarre Page 28 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 {<proxyOID> 2} - name bindings {<proxyOID> 3} - notifications The replaceByProxyOID attribute contains the "internet" OID or an organization specific OID. The portion of the OID for an internet defined object that corresponds to the replaceByProxyOID contents is replaced by {<proxyOID> 1} when translating internet object OIDs into ISO/CCITT OIDs, and {<proxyOID> 3} when translating internet trap OIDs into ISO/CCITT notification OIDs. The managementProtocol attribute specifies the Internet management protocol used by the proxy to manage devices. It may be an OID indicating SNMP, SNMP-2, or some other protocol. This attribute is assigned a value (an OID) by the manager that is appropriate to the agent. The supportedMIBs attribute contains the set of OIDs of registered MIBs that the agent supports. The manager may add or remove elements to/from this attribute. The specificAccessControlUsed attribute indicates whether access control specific to an SNMP agent is none, uses Internet defined mechanisms and MIB elements, or uses ISO/CCITT defined mechanisms and MIB elements. The accessControlEnforcement attribute indicates where access control is applied: SNMP agent, proxy, or both. The operationalState attribute indicates the perceived state of the agent in the managed system: The "enabled" state means that the agent is operational, as perceived by the proxy, i.e., it can be reached. The "disabled" state means that the agent is not operational, as perceived by the proxy, i.e., it cannot be reached. The administrativeState attribute is used to suspend and resume the proxy activity relative to the agent. The "unlocked" state means that proxy must continue to perform, or resume performing, proxy activities on behalf of the agent. LaBarre Page 29 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 The "locked" state means that the proxy must not perform, or suspend performing, proxy activities on behalf of the agent. The authenticationFailure notification is emitted when the SNMP agent is the addressee of a protocol message that is not properly authenticated. The coldStart notification is emitted when the SNMP agent reinitializes itself such that its configuration may be altered. The warmStart notification is emitted when the SNMP agent reinitializes itself such that its configuration is not altered. This object class may have MULTIPLE INSTANCES.!;; ATTRIBUTES cmipsnmpProxyAgentId GET, proxyOID GET-REPLACE, replacedByProxyOID GET-REPLACE, managementProtocol GET REPLACE-WITH-DEFAULT, supportedMIBs GET-REPLACE ADD-REMOVE, specificAccessControlUsed GET-REPLACE DEFAULT VALUE CmipsnmpProxyASN1.Zero, accessControlEnforcement GET-REPLACE, "Rec. X.721 | ISO/IEC 10165-2 : 1992": administrativeState GET-REPLACE, "Rec. X.721 | ISO/IEC 10165-2 : 1992": operationalState GET; NOTIFICATIONS authenticationFailure, coldStart, warmStart;;; REGISTERED AS { cmipsnmpProxyPMIB 1 1}; cmipsnmpProxyTable MANAGED OBJECT CLASS DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992" :top; CHARACTERIZED BY cmipsnmpProxyTablePkg PACKAGE BEHAVIOUR cmipsnmpProxyTablePkgBehaviour BEHAVIOUR DEFINED AS !This managed object class is used to contain objects that represent an SNMP/SNMP-2 agent in the proxy MIB. The globalAccessControlUsed attribute indicates LaBarre Page 30 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 whether access control global (uniformly applied) to all SNMP agents is none, uses Internet defined mechanisms and MIB elements, or uses ISO/CCITT defined mechanisms and MIB elements.!;; ATTRIBUTES internetClassId GET, globalAccessControlUsed GET-REPLACE DEFAULT VALUE CmipsnmpProxyASN1.Zero;;; REGISTERED AS { cmipsnmpProxyPMIB 1}; accessControlEnforcement ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.AccessControlEnforcement; BEHAVIOUR accessControlEnforcementBehaviour BEHAVIOUR DEFINED AS !The accessControlEnforcement attribute indicates where access control is applied: SNMP agent, proxy, or both.!;; MATCHES FOR EQUALITY, ORDERING; REGISTERED AS {cmipsnmpProxyPMIB 1 1 7}; cmipsnmpProxyAgentId ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.CmipsnmpProxyAgentId; BEHAVIOUR cmipsnmpProxyAgentIdBehaviour BEHAVIOUR DEFINED AS !This is the naming attribute for the cmipsnmpProxyAgent object class. It contains the Internet Domain Name of the managed system that contains the SNMP/SNMP-2 agent. The value is determined by the manager at the time the object is created.!;; MATCHES FOR EQUALITY, SUBSTRINGS; REGISTERED AS {cmipsnmpProxyPMIB 1 1 1}; globalAccessControlUsed ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.AccessControlUsed; BEHAVIOUR globalAccessControlUsedBehaviour BEHAVIOUR DEFINED AS !The globalAccessControlUsed attribute indicates whether access control global (uniformly applied) to all SNMP agents is none, uses Internet defined mechanisms and MIB elements, or uses ISO/CCITT defined mechanisms and MIB elements.!;; MATCHES FOR EQUALITY, ORDERING; REGISTERED AS {cmipsnmpProxyPMIB 1 3}; internetClassId ATTRIBUTE WITH ATTRIBUTE SYNTAX LaBarre Page 31 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 CmipsnmpCommonDef.ObjectIdentifier; BEHAVIOUR internetClassIdBehaviour BEHAVIOUR DEFINED AS !This is a generic naming attribute intended to be used for naming all object classes derived from Internet MIB translation. For ISO/CCITT object classes that may have only a single instance per managed system, the value is the OID for the object class concatenated with the sub-identifier "0". Object classes derived from the Internet TCP, UDP, and IP groups are examples of such object classes. For object classes that may have multiple instances per managed system, such as table entries, the value is the concatenation of the ISO/CCITT object class OID and the Internet object instance identifier (an OID) of the form specified for the table entry instance identification in the original Internet MIB definition.!;; MATCHES FOR EQUALITY; REGISTERED AS {cmipsnmpProxyPMIB 1 2}; managementProtocol ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpCommonDef.ObjectIdentifier; BEHAVIOUR managementProtocolBehaviour BEHAVIOUR DEFINED AS !This attributes specifies the internet management protocol used for proxy to managed devices. It may be either SNMP or SNMP-2.!;; MATCHES FOR EQUALITY, ORDERING; REGISTERED AS {cmipsnmpProxyPMIB 1 1 4}; proxyOID ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpCommonDef.ObjectIdentifier; BEHAVIOUR proxyOIDBehaviour BEHAVIOUR DEFINED AS !The proxyOID attribute contains the proxy arc used in the re-registration and derivation of OIDs. The following sub-arcs are assigned: {<proxyOID> 1} - object classes, attributes {<proxyOID> 2} - name bindings {<proxyOID> 3} - notifications!;; MATCHES FOR EQUALITY, ORDERING; REGISTERED AS {cmipsnmpProxyPMIB 1 1 2}; LaBarre Page 32 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 replaceByProxyOID ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpCommonDef.ObjectIdentifier; BEHAVIOUR replaceByProxyOIDBehaviour BEHAVIOUR DEFINED AS !The replaceByProxyOID attribute contains the "internet" OID or an organization specific OID. The portion of the OID for an internet defined object that corresponds to the replaceByProxyOID contents is replaced by {<proxyOID> 1} when translating internet object OIDs into ISO/CCITT OIDs, and {<proxyOID> 3} when translating internet trap OIDs into ISO/CCITT notification OIDs!;; MATCHES FOR EQUALITY, ORDERING; REGISTERED AS {cmipsnmpProxyPMIB 1 1 3}; specificAccessControlUsed ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.AccessControlUsed; BEHAVIOUR specificAccessControlUsedBehaviour BEHAVIOUR DEFINED AS !The specificAccessControlUsed attribute indicates whether access control specific to an SNMP agent is none, uses Internet defined mechanisms and MIB elements, or uses ISO/CCITT defined mechanisms and MIB elements.!;; MATCHES FOR EQUALITY, ORDERING; REGISTERED AS {cmipsnmpProxyPMIB 1 1 6}; supportedMIBs ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.SupportedMIBs; BEHAVIOUR supportedMIBsBehaviour BEHAVIOUR DEFINED AS !This attributes specifies the set of Internet OIDs of registered MIBs that the agent supports.!;; MATCHES FOR EQUALITY, SET-COMPARISON, SET-INTERSECTION; REGISTERED AS {cmipsnmpProxyPMIB 1 1 5}; 4.2 Name Bindings ISO/CCITT-Internet proxy namebindings are registered under the {cmipsnmpProxyPMIBNB} arc which is the {cmipsnmpProxyMISC 2} arc. The name bindings are registered by appending two sub-identifiers: the first sub-identifier is associated with the object class to which the name binding applies, the second sub-identifier identifies the instance of the name binding for that object class. The second sub-identfier must be greater than or equal to 1. LaBarre Page 33 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 cmipsnmpProxyAgent-NB NAME BINDING SUBORDINATE OBJECT CLASS cmipsnmpProxyAgent AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS cmipsnmpProxyTable AND SUBCLASSES; WITH ATTRIBUTE cmipsnmpProxyAgentId; CREATE; DELETE DELETES-CONTAINED-OBJECTS; REGISTERED AS {cmipsnmpProxyPMIBNB 2 1}; cmipsnmpProxyTable-NB NAME BINDING SUBORDINATE OBJECT CLASS cmipsnmpProxyTable AND SUBCLASSES; NAMED BY SUPERIOR OBJECT CLASS "Rec. X.721 | ISO/IEC 10165-2 :1992": system AND SUBCLASSES; WITH ATTRIBUTE internetClassId; CREATE; DELETE ONLY-IF-NO-CONTAINED-OBJECTS; REGISTERED AS {cmipsnmpProxyPMIBNB 1 1}; 4.3 Common SNMP Derived Attribute Types Internet Attribute types defined by the SNMP-2 TEXTUAL- CONVENTION macro are translated into ISO/CCITT attribute types. Attributes of the defined SNMP/SNMP-2 types (Counter, IpAddress, Gauge, TimeTicks, Opaque, Counter32, Gauge32, Counter64, NsapAddress), which could also have been defined in a TEXTUAL-CONVENTION macro, are also considered to be Internet attribute types. ISO/CCITT Attribute templates derived from these types should contain the DERIVED FROM clause. The following ISO/CCITT attribute types, listed in alphabetical order, are derived from Internet attribute types to facilitate Internet MIB translation. Other attributes may be derived from these types. autonomousType ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpCommonDef.OctetString; BEHAVIOUR autonomousTypeBehaviour BEHAVIOUR DEFINED AS !Represents an independently extensible type identification value. It may, for example, indicate a particular sub-tree with further MIB definitions, or define a particular type of protocol or hardware. This corresponds to the type defined in [SMPTC] by the same name.!;; MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;; counter32 ATTRIBUTE LaBarre Page 34 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.Counter32; BEHAVIOUR counter32Behaviour BEHAVIOUR DEFINED AS !As defined for counter type in ISO/IEC 10165-2. Only the value range constraint (0..4294967295) is added. This corresponds to the type defined in [SMPSMI] by the same name!;; MATCHES FOR EQUALITY, ORDERING;; counter64 ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.Counter64; BEHAVIOUR counter64Behaviour BEHAVIOUR DEFINED AS !As defined for counter type in ISO/IEC 10165-2. Only the value range constraint (0..18446744073709551615) is added. This corresponds to the type defined in [SMPSMI] by the same name!;; MATCHES FOR EQUALITY, ORDERING;; dateAndTime ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.DateAndTime; BEHAVIOUR dateAndTimeBehaviour BEHAVIOUR DEFINED AS !DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d" A date-time specification. field octets contents range ----- ------ -------- ----- 1 1-2 year 0..65536 2 3 month 1..12 3 4 day 1..31 4 5 hour 0..23 5 6 minutes 0..59 6 7 seconds 0..60 (use 60 for leap-second) 7 8 deci-seconds 0..9 8 9 direction from UT "+" / "-" 9 10 hours from UT 0..11 10 11 minutes from UT 0..59 For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be displayed as:1992-5-26,13:30:15.0,- 4:0 Note that if only local time is known, then timezone information (fields 8-10) is not present. This corresponds to the type defined in [SMPSMI] by the same name!;; MATCHES FOR EQUALITY, ORDERING;; LaBarre Page 35 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 displayString ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpCommonDef.OctetString; BEHAVIOUR displayStringBehaviour BEHAVIOUR DEFINED AS !DISPLAY-HINT "255a" Represents textual information taken from the NVT ASCII character set, as defined in pages 4, 10-11 of RFC 854. Any object defined using this syntax may not exceed 255 characters in length. This corresponds to the type defined in [SMPTC] by the same name.!;; MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;; gauge32 ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.Gauge32; BEHAVIOUR gauge32Behaviour BEHAVIOUR DEFINED AS !As defined for the integer gauge type in ISO/IEC 10165-2. Only the value range constraint (0..4294967295) is added. This corresponds to the type defined in [SMPSMI] by the same name!;; MATCHES FOR EQUALITY, ORDERING;; instancePointer ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpCommonDef.ObjectIdentifier; BEHAVIOUR instancePointerBehaviour BEHAVIOUR DEFINED AS !A pointer to a specific instance of a conceptual row of a MIB table in the managed device. By convention, it is the name of the particular instance of the first columnar object in the conceptual row. This corresponds to the type defined in [SMPTC] by the same name.!;; MATCHES FOR EQUALITY, ORDERING;; ipAddress ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpCommonDef.OctetString; BEHAVIOUR ipAddressBehaviour BEHAVIOUR DEFINED AS !This attribute represents a 32-bit internet address. It is represented as an octet string of length 4, in network Byte-order. This corresponds to the type defined in [SMPSMI] by the same name!;; MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;; macAddress ATTRIBUTE LaBarre Page 36 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.MacAddress; BEHAVIOUR macAddressBehaviour BEHAVIOUR DEFINED AS !DISPLAY-HINT "1x:" Represents an 802 MAC address represented in the `canonical' order defined by IEEE 802.1a, i.e., as if it were transmitted least significant bit first, even though 802.5 (in contrast to other 802.x protocols) requires MAC addresses to be transmitted most significant bit first. This corresponds to the type defined in [SMPTC] by the same name.!;; MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;; nsapAddress ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpCommonDef.OctetString; BEHAVIOUR nsapAddressBehaviour BEHAVIOUR DEFINED AS !This attribute represents an ISO/CCITT network address. It is represented as a variable length octet string. The first octet of the string contains a binary value, in the range of 0..20, and indicates the length in octets of the NSAP. Following the first octet, is the NSAP expressed in concrete binary notation, starting with the most significant octet. A zero-length NSAP is used as a "special" address, meaning "the default NSAP" (analogous to the IP address of 0.0.0.0). Such an NSAP is encoded as a single octet containing the value 0. All other NSAPS are encoded in at least 4 octets. This corresponds to the type defined in [SMPSMI] by the same name!;; MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;; opaque ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpCommonDef.OctetString; BEHAVIOUR opaqueBehaviour BEHAVIOUR DEFINED AS !This attribute represents arbitrary ASN.1 syntax. A value is encoded using the Basic Encoding Rules [ISO8825] into a string of octets. This, in turn, is encoded as an OCTET STRING, in effect "double-wrapping" the original ASN.1 value. This corresponds to the type defined in [SMPSMI] by the same name.!;; MATCHES FOR EQUALITY, ORDERING;; physAddress ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpCommonDef.OctetString; BEHAVIOUR LaBarre Page 37 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 physAddressBehaviour BEHAVIOUR DEFINED AS !DISPLAY-HINT "1x:" Represents media- or physical-level addresses. This corresponds to the type defined in [SMPTC] by the same name.!;; MATCHES FOR EQUALITY, ORDERING, SUBSTRINGS;; rowStatus ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.RowStatus; BEHAVIOUR rowStatusBehaviour BEHAVIOUR DEFINED AS !The syntax used for the status column for a conceptual row. If present, the value of the DEFVAL clause for an object having this syntax is either `underModification(3)' or `active(4)'. To create new object instances for a conceptual row, a management protocol set operation is issued which sets the new instance of the status column to `underCreation(1)'. If the instance already exists, then the management protocol set operation fails with an error of `inconsistentValue'. Otherwise, the instance is created. If the management protocol set operation created sufficient instances so that this conceptual row may be used by the correspondent SMP entity, and the value of the DEFVAL clause for the status column is `active(4)', then the SMP entity acting in an agent role immediately sets the value of this instance to `active(4)'. Otherwise, the SMP entity acting in an agent role immediately sets the value of this instance to `underModification(3)'. See [SMPTC] for a description of the algorithm to create a new conceptual row. This corresponds to the type defined in [SMPTC] by the same name.!;; MATCHES FOR EQUALITY, ORDERING;; testAndIncrement ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.TestAndIncrement; BEHAVIOUR testAndIncrementBehaviour BEHAVIOUR DEFINED AS !Represents integer-valued information used for atomic operations. When the management protocol is used to specify that an object instance having LaBarre Page 38 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 this syntax is to be modified, the new value supplied via the management protocol must precisely match the value presently held by the instance. If not, the management protocol set operation fails with an error of `inconsistentValue'. Otherwise, if the current value is the maximum value of 2^31-1 (2147483647 decimal), then the value held by the instance is wrapped to zero; otherwise, the value held by the instance is incremented by one. (Note that regardless of whether the management protocol set operation succeeds, the previous value held by the instance is returned.) The value of the ACCESS clause for objects having this syntax is either `read-write' or `read- create'. When an instance of a columnar object having this syntax is created, any value may be supplied via the management protocol. This corresponds to the type defined in [SMPTC] by the same name.!;; MATCHES FOR EQUALITY, ORDERING;; timeInterval ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.Integer32; BEHAVIOUR timeIntervalBehaviour BEHAVIOUR DEFINED AS !A period of time, measured in units of 0.01 seconds. This corresponds to the type defined in [SMPTC] by the same name.!;; MATCHES FOR EQUALITY, ORDERING;; timeStamp ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.TimeTicks; BEHAVIOUR timeStampBehaviour BEHAVIOUR DEFINED AS !The value of MIB-II's sysUpTime object at which a specific occurrence happened. The specific occurrence must be defined in the description of any object defined using this type. This corresponds to the type defined in [SMPTC] by the same name.!;; MATCHES FOR EQUALITY, ORDERING;; timeTicks ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.TimeTicks; BEHAVIOUR timeTicksBehaviour BEHAVIOUR LaBarre Page 39 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 DEFINED AS !This attribute represents a non-negative integer which represents the time, modulo 2->32 (4294967296 decimal), in hundredths of a second between two epochs. When attributes are defined which use this attribute type, the description of the object identifies both of the reference epochs. This corresponds to the type defined in [SMPSMI] by the same name!;; MATCHES FOR EQUALITY, ORDERING;; truthValue ATTRIBUTE WITH ATTRIBUTE SYNTAX CmipsnmpProxyASN1.TruthValue; BEHAVIOUR truthValueBehaviour BEHAVIOUR DEFINED AS !Represents a boolean value. This corresponds to the type defined in [SMPTC] by the same name.!;; MATCHES FOR EQUALITY;; 4.4 Notifications for SNMP/SNMP-2 Traps Notification templates for the SNMP generic traps are listed here in alphabetical order. They are registered under the {cmipsnmpProxyNOT} arc with sub-identifiers allocated according to the SNMP-2 assignment for generic traps. Pending progression of SNMP-2 to an Internet standard, and the subsequent assignment of OIDs under the "internet" arc, this memo has not assigned OIDs for the standard notifications defined in [RFC1157] and [SMPMIB]. authenticationFailure NOTIFICATION BEHAVIOUR authenticationFailureBehaviour BEHAVIOUR DEFINED AS !This notification maps to the authenticationFailure generic trap defined in RFC 1157, i.e., generic-trap=4. An authenticationFailure notification signifies that the SNMP/SNMP-2 entity, acting in an agent role, has received a protocol message that is not properly authenticated. The snmpEnableAuthentraps attribute of the snmp object class indicates whether this notification will be generated by an SNMP agent.!;; WITH INFORMATION SYNTAX CmipsnmpProxyASN1.MonitoredAttributes AND ATTRIBUTE IDS monitoredAttributes "Rec. X.721 | ISO/IEC 10165-2 : 1992" :monitoredAttributes; LaBarre Page 40 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 REGISTERED AS {cmipsnmpProxyNOT ?}; coldStart NOTIFICATION BEHAVIOUR coldStartBehaviour BEHAVIOUR DEFINED AS !This notification maps to the coldStart generic trap defined in RFC 1157, i.e., generic-trap=0. A coldStart notification signifies that an SNMP/SNMP-2 entity acting in an agent role, is reinitializing itself such that its configuration may be altered.!;; WITH INFORMATION SYNTAX CmipsnmpProxyASN1.MonitoredAttributes AND ATTRIBUTE IDS monitoredAttributes "Rec. X.721 | ISO/IEC 10165-2 : 1992" :monitoredAttributes; REGISTERED AS {cmipsnmpProxyNOT ?}; egpNeighborLoss NOTIFICATION BEHAVIOUR egpNeighborLossBehaviour BEHAVIOUR DEFINED AS !This notification maps to the egpNeighborLoss generic trap defined in RFC 1157, i.e., generic- trap=5. An egpNeighborLoss notification signifies that an EGP neighbor has been marked down and the RGP peer relationship no longer obtains.!;; WITH INFORMATION SYNTAX CmipsnmpProxyASN1.MonitoredAttributes AND ATTRIBUTE IDS monitoredAttributes "Rec. X.721 | ISO/IEC 10165-2 : 1992" :monitoredAttributes; REGISTERED AS {cmipsnmpProxyNOT ?}; linkDown NOTIFICATION BEHAVIOUR linkDownBehaviour BEHAVIOUR DEFINED AS !This notification maps to the linkDown generic trap defined in RFC 1157, i.e., generic-trap=2. The ifIndex of the interface causing the event shall appear in the monitored attributes. A linkdown notification signifies that the SNMP/SNMP-2, entity acting in an agent role, recognizes a failure in one of the communication links represented in its configuration.!;; LaBarre Page 41 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 WITH INFORMATION SYNTAX Attribute-ASN1Module.MonitoredAttributes AND ATTRIBUTE IDS monitoredAttributes "Rec. X.721 | ISO/IEC 10165-2 : 1992" :monitoredAttributes; REGISTERED AS {cmipsnmpProxyNOT ?}; linkUp NOTIFICATION BEHAVIOUR linkUpBehaviour BEHAVIOUR DEFINED AS !This notification maps to the linkUp generic trap defined in RFC 1157, i.e., generic-trap=3. The ifIndex of the interface causing the event shall appear in the monitoredAttributes. A linkup notification signifies that the SNMP/SNMP-2, entity acting in an agent role, recognizes that one of the communication links represented in its configuration has come up.!;; WITH INFORMATION SYNTAX CmipsnmpProxyASN1.MonitoredAttributes AND ATTRIBUTE IDS monitoredAttributes "Rec. X.721 | ISO/IEC 10165-2 : 1992" :monitoredAttributes; REGISTERED AS {cmipsnmpProxyNOT ?}; warmStart NOTIFICATION BEHAVIOUR warmStartBehaviour BEHAVIOUR DEFINED AS !This notification maps to the warmStart generic trap defined in RFC 1157, i.e., generic-trap=1. A warmstart notification signifies that an SNMP/SNMP-2 entity acting in an agent role, is reinitializing itself such that its configuration is unaltered.!;; WITH INFORMATION SYNTAX CmipsnmpProxyASN1.MonitoredAttributes AND ATTRIBUTE IDS monitoredAttributes "Rec. X.721 | ISO/IEC 10165-2 : 1992" :monitoredAttributes; REGISTERED AS {cmipsnmpProxyNOT ?}; 4.5 ASN.1 Definitions CmipsnmpProxyAssignedOIDs {cmipsnmpProxyPMIBMOD 1} DEFINITIONS ::= BEGIN EXPORTS ;-- EVERYTHING LaBarre Page 42 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 cmipsnmpProxy OBJECT IDENTIFIER ::= {...} cmipsnmpProxyIMIB OBJECT IDENTIFIER ::= {cmipsnmpProxy 1} -- for ISO/CCITT derived object classes and attributes cmipsnmpProxyNB OBJECT IDENTIFIER ::= {cmipsnmpProxy 2} -- for ISO/CCITT derived NAME BINDINGS cmipsnmpProxyNOT OBJECT IDENTIFIER ::= {cmipsnmpProxy 3} -- for ISO/CCITT Notifications cmipsnmpProxyPMIB OBJECT IDENTIFIER ::= {cmipsnmpProxy 4} -- for ISO/CCITT Proxy MIB defined in this memo cmipsnmpProxyPMIBNOT OBJECT IDENTIFIER ::= {cmipsnmpProxy 5} -- for standard SNMP notifications cmipsnmpProxyPMIBNB OBJECT IDENTIFIER ::= {cmipsnmpProxy 6} -- for ISO/CCITT Proxy MIB NAME BINDINGS cmipsnmpProxyPMIBMOD OBJECT IDENTIFIER ::= {cmipsnmpProxy 7} -- for ISO/CCITT Proxy MIB ASN.1 Modules cmipsnmpProxyMISC OBJECT IDENTIFIER ::= {cmipsnmpProxy 8} -- for micellaneous snmpOID OBJECT IDENTIFIER ::= {cmipsnmpProxyMISC 1} snmp2OID OBJECT IDENTIFIER ::= {cmipsnmpProxyMISC 1} -- required for management protocol identification END {Editor's Note: Should OIDs be assigned for SNMP and SNMP-2 in this document?} CmipsnmpCommonDef {cmipsnmpProxyPMIBMOD 2} DEFINITIONS ::= BEGIN EXPORTS -- EVERYTHING Integer, OctetString, ObjectIdentifier, Null, BitString; -- Integer ::= INTEGER OctetString ::= OCTET STRING ObjectIdentifier ::= OBJECT IDENTIFIER Null ::= NULL BitString ::= BIT STRING END CmipsnmpProxyASN1 {cmipsnmpProxyPMIBMOD 3} DEFINITIONS ::= BEGIN IMPORTS MonitoredAttributes FROM Attribute-ASN1Module; -- defined in -- Rec. X.721 | ISO/IEC 10165-2 : 1992, Counter32 ::= INTEGER (0..4294967295) Counter64 ::= INTEGER (0..18446744073709551615) DateAndTime ::= ::= OCTET STRING (SIZE (8 | 11)) Gauge32 ::= INTEGER (0..4294967295) TimeTicks ::= INTEGER (0..4294967295) MacAddress ::= OCTET STRING (SIZE (6)) TruthValue ::= INTEGER { true(1), false(2) } LaBarre Page 43 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 TestAndIncrement ::= INTEGER (0..2147483647) RowStatus ::= INTEGER { active(1) underConstruction(2), underDestruction(3), underModification(4), } CmipsnmpProxyAgentId ::= GraphicString AccessControlUsed ::= INTEGER { none (1), internet (2), osi (3)} AccessControlEnforcement ::= INTEGER { agent (1), proxy (2), both (3)} SupportedMIBs ::= SET OF OBJECT IDENTIFIER Zero ::= INTEGER 0 END 4.6 ISO/CCITT-Internet Proxy Communications An ISO/CCITT-Internet proxy requires knowledge of the SNMP agent's "community string" or SNMP "party" values to communicate with the agent. This information may be placed in MIB elements defined in the SNMP Party MIB [IIMCPARTY] which is derived from the Internet MIB defined in [RFC1353]. Therefore the proxy must also include, at a minimum, the "partyTable" and "partyEntry" object classes defined in [IIMCPARTY]. These object classes contain the information required for party-based security (including authentication, integrity, and confidentiality services), and are adapted for use with community-based security. The MIB defined in [RFC1353] is also included in the SNMP-2 MIB [SMPMIM]. The Party MIB may also contain information required for controlling access to operations on management information based on an access control list mechanism. Access control list information is contained the "aclTable" entries. Constraints on what information may be accessed may be placed in the "viewTable" entries. 5. Acknowledgements The author thanks the following individuals for their insightful comments and contributions: Jon Biggar - NETLABS April Chang - NETLABS Dean Voiss - NETLABS Jock Embry - Opening Technologies Steve Ng - MPR Teltech LaBarre Page 44 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 Lisa Phifer - Bellcore Owen Newnan - US West Advanced Technologies LaBarre Page 45 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 References [ISO8824] ISO/IEC IS 8824: Information Technology - Open System Interconnection - Specification of Abstract Syntax Notation One (ASN.1),1990. [ISO8825] ISO/IEC IS 8825: Information Technology - Open System Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1),1990. [ISO7498-4] ISO/IEC IS 7498-4, Information Processing Systems - Open Systems Interconnection - Basic Reference Model Part 4 - Management Framework, 1989. [ISO9595] ISO/IEC IS 9595, Information Technology - Open SystemInterconnection - Common Management Information Service Definition, 1991. [ISO9596-1] ISO/IEC IS 9596-1, Information Technology - Open Systems Interconnection - Common Management Information Protocol - Part 1: Specification, 1991. ISO10165-1] ISO/IEC IS 10165-1: Information Technology - Open Systems Interconnection - Structure of Management Information - Part 1: Management Information Model, 1991. [ISO10165-2] ISO/IEC IS 10165-2: Information Technology - Open Systems Interconnection - Structure of Management Information - Part 2:Definition of Management Information, 1992. [ISO10165-4] ISO/IEC IS 10165-4: Information Technology - Open Systems Interconnection - Structure of Management Information - Part 4: Guidelines for the Definition of Managed Objects, 1991. [RFC1155] RFC1155, M. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP based internets, May 1990. [RFC1157] RFC 1157, J.D. Case, M.S. Fedor, M.L. Schoffstall, C. Davin, Simple Network Management Protocol (SNMP), May 1990. [RFC1212] RFC1212, M. Rose, K. McCloghrie - Editors, Concise MIB Definitions, March 1991. [RFC1213] RFC1213, K. McCloghrie and M. Rose - Editors, Management Information Base for Network Management of TCP/IP-based internets: MIB-II, March 1991. [RFC1214] RFC1214, L. LaBarre - editor, OSI Internet Management:Management Information Base, April 1991. LaBarre Page 46 Draft Translation of Internet MIBs to ISO/CCITT MIBs 10/9/1992 [RFC1215] RFC1215, M. Rose - Editor, Management A convention for Defining Traps for use with the SNMP, March 1991. [RFC1353] RFC1353, K. McCloghrie, J.R. Davin, J.M. Galvin, Definitions of Managed Objects for SNMP Parties, July 1992. [SMPCOEX] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Coexistance between the Internet-standard Network Management Framework and the Simple Management Protocol (SMP) Framework, Internet-draft, October 1992. [SMPPROT] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Protocol Operations for the Simple Management Protocol (SMP) Framework, Internet-draft, October 1992. [SMPSMI] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Protocol Structure of Management Information for the Simple Management Protocol (SMP) Framework, Internet- draft, October 1992. [SMPMIB] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Management Information Base for the Simple Management Protocol (SMP) Framework, Internet-draft, October 1992. [SMPTC] J.D. Case, K. McCloghrie, M.T. Rose, S.L. Waldbusser, Textual Conventions for the Simple Management Protocol (SMP) Framework, Internet-draft, October 1992. [IIMCPARTY] L. LaBarre, ISO/CCITT and Internet Management Coexistence: Translation of Internet Party MIB (RFC1353) to ISO/CCITT GDMO MIB, October 1992. [IIMCMIB-II] L. LaBarre, ISO/CCITT and Internet Management Coexistence: Translation of Internet MIB-II (RFC1213) to ISO/CCITT GDMO MIB, October 1992. [IIMCPROXY] A. Chang, ISO/CCITT and Internet Management Coexistence: ISO/CCITT to Internet Management Proxy, October 1992. [IIMCOMIBTRANS] O. Newnan, ISO/CCITT and Internet Management Coexistence: Translation of ISO/CCITT GDMO MIBs to Internet MIBs, October 1992. [NMFMC92] NM Forum and X/Open, ISO/CCITT/CCITT and Internet Management: Coexistence and Interworking Strategy, October, 1992. - INTERNET DRAFT Expires April 23 , 1993 - LaBarre Page 47